dBase III 및 IV 표준에 대한 심층 분석 안내서

1. 서론: PC 데이터베이스 시대의 서막, dBase 표준의 정의

1980년대, 개인용 컴퓨터(PC)의 등장은 비즈니스 환경을 근본적으로 바꾸었으나, 데이터 관리의 복잡성은 여전히 큰 장벽으로 남아 있었다. 메인프레임과 미니컴퓨터에서나 가능했던 체계적인 데이터 관리는 일반 사무 환경에서는 요원한 일이었다. 이 기술적 공백기에 등장한 애슈턴-테이트(Ashton-Tate)의 dBase는 단순한 소프트웨어 제품을 넘어, PC 기반 데이터 관리의 패러다임을 제시하고 하나의 산업 생태계를 창조한 ’사실상 표준(de facto standard)’으로 부상했다.1 dBase의 성공은 PC가 단순한 계산기나 워드프로세서를 넘어, 중소기업의 핵심 비즈니스 로직을 처리하는 강력한 도구로 자리매김하게 한 결정적 계기가 되었다.

본 안내서는 ’dBase 표준’의 실체를 다각적으로 규명하는 것을 목표로 한다. 여기서 ’표준’이란 국제표준화기구(ISO)와 같은 공식 기구가 제정한 ’공식 표준(de jure standard)’이 아니라, 압도적인 시장 점유율과 영향력을 바탕으로 업계 전반에서 통용되는 규범과 기술의 집합체를 의미한다. 따라서 본 안내서에서 정의하는 ’dBase 표준’은 다음 세 가지 핵심적인 축으로 구성된다.

1. 기술적 표준 (Technical Standard): 데이터를 물리적으로 저장하는 .dbf 파일 포맷과, 검색 속도 향상을 위한 인덱스 파일(.ndx, .mdx), 그리고 대용량 텍스트 저장을 위한 메모 파일(.dbt)의 명세 및 구조를 의미한다. 이 구조의 단순성과 개방성은 dBase 생태계 확장의 근간이 되었다.

2. 언어적 표준 (Linguistic Standard): 데이터를 생성, 조회, 수정, 삭제(CRUD)하고 응용 프로그램을 개발하는 데 사용된 dBase 프로그래밍 언어의 문법과 명령어 체계를 지칭한다. 이 언어는 이후 Clipper, FoxPro 등 수많은 파생 제품을 낳으며 ’xBase’라는 거대한 언어군으로 확장되었다.

3. 생태계적 표준 (Ecosystem Standard): dBase를 중심으로 형성된 방대한 서드파티 개발자, 부가 가치 재판매업자(VAR), 컨설턴트, 교육 및 출판 시장을 포함한다. 이 생태계는 dBase의 시장 지배력을 공고히 하고, 기술적 단점에도 불구하고 그 생명력을 오랫동안 유지시킨 핵심 동력이었다.

본 안내서는 먼저 dBase의 기원부터 시작하여 dBase III Plus 버전에 이르기까지 이 세 가지 표준이 어떻게 확립되었는지를 역사적으로 추적한다. 이후, dBase III 표준의 기술적 핵심인 파일 포맷과 프로그래밍 언어를 심층적으로 해부하여 그 구조와 작동 원리를 분석한다. 다음으로, dBase IV에서 시도된 표준의 진화, 즉 다중 인덱스 파일(.mdx)과 SQL 지원과 같은 혁신적 기능들을 살펴보고, 이 야심 찬 시도가 왜 기술적 재앙과 시장의 외면으로 귀결되었는지를 분석한다. 마지막으로, dBase의 실패 이후 xBase라는 이름으로 확장된 생태계와 dBase가 현대 컴퓨팅에 남긴 지속적인 유산을 조망하며 안내서를 마무리한다. 이를 통해 dBase 표준의 영광과 교훈을 종합적으로 고찰하고자 한다.

2. dBase의 탄생과 발전: 표준의 확립

2.1 기원: JPLDIS에서 Vulcan까지

dBase의 기술적 뿌리는 의외의 장소, 즉 1960년대 후반 미국 항공우주국(NASA)의 제트추진연구소(Jet Propulsion Laboratory, JPL)에서 시작되었다. 당시 JPL의 프레드 톰슨(Fred Thompson)은 고가의 전자계산기 데이터베이스를 관리하기 위해 Tymshare사의 ’RETRIEVE’라는 제품을 사용하고 있었다.4 1971년, 톰슨은 동료 프로그래머 잭 햇필드(Jack Hatfield)와 협력하여 RETRIEVE의 강화된 버전을 개발했는데, 이것이 바로 ‘JPLDIS(Jet Propulsion Laboratory Display Information System)’ 프로젝트였다.4 JPLDIS는 UNIVAC 1108 메인프레임 컴퓨터에서 FORTRAN 언어로 작성되었으며, 거대 기관의 데이터 관리 요구를 충족시키기 위한 비상업적 목적의 산물이었다.4

이 기관 내부용 기술이 개인용 컴퓨터 혁명의 씨앗으로 전환된 계기는 JPL의 계약직 프로그래머였던 C. 웨인 랫리프(C. Wayne Ratliff)의 개인적인 동기에서 비롯되었다. 그는 사내 풋볼 경기 결과를 분석하여 우승자를 예측하는 데 흥미를 느꼈고, 이를 위해 데이터베이스 시스템이 필요했다.4 그는 우연히 JPLDIS의 문서를 접하게 되었고, 그 개념을 기반으로 자신이 직접 조립한 IMSAI 8080 마이크로컴퓨터에서 동작하는 데이터베이스 시스템을 개발하기 시작했다.4 PTDOS 운영체제 위에서 인텔 8080 어셈블리어로 작성된 이 시스템에 그는 ’벌칸(Vulcan)’이라는 이름을 붙였다. 이는 인기 SF 시리즈 ’스타 트렉’에 등장하는 스팍의 고향 행성 이름에서 따온 것이었다.4 이처럼 dBase의 직접적인 전신인 Vulcan은 거대한 기관의 기술이 한 개인의 손을 거쳐 PC라는 새로운 플랫폼에서 재탄생한 상징적인 사건이었으며, 이는 향후 PC 소프트웨어 산업의 발전 방향을 예고하는 것이었다.

2.2 Ashton-Tate와 dBase II: 상업적 표준의 서막

랫리프는 Vulcan을 개인적으로 판매하려 했으나 큰 성공을 거두지는 못했다. 전환점은 1980년, 소프트웨어 유통업계에서 성공 가도를 달리던 조지 테이트(George Tate)와 할 래슐리(Hal Lashlee)가 Vulcan의 잠재력을 발견하면서 찾아왔다.4 그들은 랫리프와 라이선스 계약을 체결하고, Vulcan을 전문적으로 마케팅하기 위한 새로운 회사 ’애슈턴-테이트(Ashton-Tate)’를 설립했다.5 ’애슈턴’이라는 이름은 실제 인물이 아니라, 단순히 전문적이고 신뢰감 있는 이미지를 주기 위해 조지 테이트의 이름과 결합된 마케팅용 상표였다.5

애슈턴-테이트의 성공은 기술 자체가 아닌, 탁월한 마케팅과 비즈니스 전략에 있었다. 그들은 초기 소프트웨어 역사상 가장 성공적인 마케팅 전략 중 하나를 실행했다. 광고 대행사의 제안에 따라 제품명을 ’Vulcan’에서 ’dBase II’로 변경한 것이다.5 실제로는 첫 상용 버전이었음에도 불구하고 숫자 ’II’를 붙임으로써, 마치 한 차례 개선을 거친 안정된 두 번째 버전인 것처럼 보이게 했다. 이는 신생 소프트웨어에 대한 소비자의 잠재적 불안감을 해소하고 제품의 신뢰성을 효과적으로 부각시키는 역할을 했다.5 또한, 700달러라는 높은 가격 정책은 dBase를 단순한 유틸리티가 아닌 전문가용 고급 소프트웨어로 포지셔닝하는 데 기여했다.5

dBase II는 당시 마이크로컴퓨터 시장의 표준 운영체제였던 CP/M에서 큰 성공을 거두었다.2 그리고 1981년 IBM PC가 출시되자, 애슈턴-테이트는 이 새로운 플랫폼으로 신속하게 dBase II를 이식했다.2 이는 dBase가 PC 시장을 선점하는 결정적인 계기가 되었다. 당시 IBM PC에서 사용할 수 있는 전문 비즈니스 소프트웨어는 극소수에 불과했기 때문에, dBase II는 워드프로세서인 WordStar, 스프레드시트인 VisiCalc와 함께 PC 시대의 3대 ’킬러 애플리케이션’으로 자리매김했다.2 이는 dBase가 단순히 유용한 소프트웨어를 넘어, PC라는 하드웨어 자체의 구매를 견인하는 핵심 동력이었음을 의미한다.

2.3 dBase III와 III Plus: 사실상 표준의 완성

dBase II의 성공에도 불구하고 기술적인 한계는 명확했다. 8080 어셈블리어로 작성되었기 때문에 특정 CPU 아키텍처에 종속되어 다른 플랫폼으로의 이식성이 매우 떨어졌다.7 마이크로컴퓨터 시장이 다변화되면서 이는 심각한 제약이 되었다. 이러한 한계를 극복하기 위해 애슈턴-테이트는 1984년, C언어로 완전히 재작성한 dBase III를 출시했다.7 C언어로의 전환은 장기적으로 다양한 플랫폼으로의 확장을 염두에 둔 전략적 결정이었다. 그러나 이 결정에는 대가가 따랐다. 초기 dBase III 버전은 최적화 문제로 인해 어셈블리어로 잘 짜인 dBase II보다 실행 속도가 현저히 느리다는 비판에 직면했다.7 이는 고성능 어셈블리 코드베이스를 고급 언어로 전환할 때 발생하는 전형적인 트레이드오프를 보여주는 사례이며, 훗날 dBase IV의 실패를 예고하는 복선이기도 했다.

성능 문제에도 불구하고 dBase III는 중요한 개선을 이루었다. 특히 초보 사용자를 위해 ’어시스턴트(The Assistant)’라는 메뉴 기반 인터페이스를 도입한 것은 주목할 만하다.10 기존의 닷 프롬프트(.) 방식은 전문가에게는 강력했지만 일반 사용자가 배우기에는 진입 장벽이 높았다. 어시스턴트는 사용자가 메뉴를 통해 데이터베이스 생성, 수정, 조회 등의 작업을 수행할 수 있게 함으로써 dBase의 사용자층을 넓히는 데 기여했다.10

dBase 표준이 진정으로 완성된 것은 1986년에 출시된 dBase III Plus를 통해서였다. 이 버전은 dBase III의 불안정성과 성능 문제를 대폭 개선했을 뿐만 아니라, 당시 기업 환경의 핵심 요구사항이었던 LAN(Local Area Network) 환경에서의 다중 사용자 지원 기능을 추가했다.7 여러 사용자가 네트워크를 통해 동시에 동일한 데이터베이스에 접근하고 수정할 수 있게 되면서, dBase는 개인용 데이터 관리 도구를 넘어 부서 단위의 업무를 처리하는 협업 플랫폼으로 진화했다. 이 시점에서 dBase는 개인 및 중소기업 데이터베이스 시장에서 경쟁자를 압도하는 확고한 표준으로 자리 잡았으며, dBase III Plus는 이후 수년간 안정성과 기능성의 기준으로 평가받았다.

이러한 발전 과정을 통해 드러나는 중요한 점은 dBase의 성공이 기술적 기원과 상업적 성공의 분리에서 비롯되었다는 사실이다. dBase의 핵심 기술은 JPL이라는 공공 기관에서 비상업적 목적으로 탄생했지만, 그 잠재력을 알아보고 시장 표준으로 만든 것은 애슈턴-테이트의 탁월한 마케팅과 비즈니스 전략이었다. 이는 초기 소프트웨어 산업에서 기술적 우위만큼이나 시장을 읽고 제품을 상품화하는 능력이 얼마나 중요했는지를 명확히 보여준다. Vulcan이라는 기술적 토대 위에 ’dBase II’라는 브랜드 네이밍, 전문 소프트웨어로서의 가격 정책, 그리고 IBM PC로의 신속한 시장 진입이라는 비즈니스 결정이 결합되면서 비로소 ’dBase 표준’이 탄생할 수 있었던 것이다.

3. dBase III 표준의 기술적 해부

dBase III가 확립한 표준의 핵심은 그 기술적 명세에 있다. 특히 데이터를 물리적으로 저장하는 .dbf 파일의 구조, 데이터의 무결성과 검색 속도를 보장하는 보조 파일들, 그리고 이 모든 것을 제어하는 프로그래밍 언어는 dBase 생태계의 근간을 이루었다. 이 기술적 기반의 단순성과 명확성은 dBase가 다른 소프트웨어와의 데이터 교환에서 중심적인 역할을 수행하게 한 원동력이었다.

3.1 .dbf 파일 포맷 심층 분석

dBase 표준의 물리적 실체인 .dbf 파일은 명확하게 정의된 이진 구조를 가진다. 이 파일은 크게 파일 헤더(header)와 데이터 레코드(data records)라는 두 영역으로 구성된다.12 복잡한 트랜잭션 로그나 부가적인 메타데이터 없이 데이터의 구조와 내용만을 담고 있는 이 단순하고 잘 문서화된 구조는 dBase의 가장 큰 자산이었다. 덕분에 수많은 서드파티 애플리케이션들이 .dbf 파일을 쉽게 읽고 쓸 수 있었고, 이는 dBase를 넘어선 사실상의 데이터 교환 표준(de facto standard for data interchange)으로 자리 잡는 결정적 계기가 되었다.14

3.1.1 파일 헤더 구조

파일의 가장 첫 부분에 위치하는 헤더는 데이터베이스 테이블 전체에 대한 핵심 메타데이터를 담고 있다. dBase III Plus의 헤더는 고정된 크기를 가지며, 각 바이트는 명확한 용도를 가진다.12 프로그램은 이 헤더 정보를 먼저 읽어들임으로써 실제 데이터에 접근하기 전에 테이블의 전체 구조와 상태를 신속하게 파악할 수 있다. 헤더의 주요 정보는 다음과 같다.

• 파일 타입 (Byte 0): 파일의 버전을 나타내는 1바이트 플래그. dBase III Plus의 경우, 메모(.dbt) 파일이 없으면 0x03, 있으면 0x83 값을 가진다.13

• 마지막 업데이트 날짜 (Byte 1-3): 3바이트로, 각각 년(YY), 월(MM), 일(DD)을 이진 형태로 저장한다.

• 레코드 수 (Byte 4-7): 32비트 little-endian 정수(long integer)로, 파일에 저장된 전체 레코드의 개수를 나타낸다.

• 헤더 크기 (Byte 8-9): 16비트 little-endian 정수(word)로, 헤더 영역 전체의 바이트 단위 크기를 명시한다. 이 값을 통해 데이터 레코드가 시작되는 위치를 정확히 계산할 수 있다.

• 레코드 크기 (Byte 10-11): 16비트 little-endian 정수(word)로, 레코드 하나가 차지하는 고정된 바이트 크기를 나타낸다. 모든 레코드는 동일한 크기를 가지므로, 특정 레코드의 위치는 헤더 크기 + (레코드 번호 - 1) * 레코드 크기와 같은 간단한 수식으로 즉시 계산될 수 있다.

이처럼 구조화된 헤더 정보는 dBase가 대용량 파일을 효율적으로 처리할 수 있는 기반을 제공했다. 아래 표는 dBase III Plus의 .dbf 파일 헤더 구조를 상세히 보여준다.

Table 1: dBase III Plus .dbf 파일 헤더 구조

3.1.2 필드 디스크립터 배열

헤더의 기본 정보 영역 바로 뒤에는 테이블의 각 필드(열)를 상세히 정의하는 ’필드 디스크립터(field descriptor)’들의 배열이 이어진다. 각 필드 디스크립터는 32바이트의 고정된 크기를 가지며, 테이블에 필드가 10개 있다면 320바이트의 공간을 차지한다.12 dBase III Plus는 테이블당 최대 128개의 필드를 가질 수 있었다.13 각 디스크립터는 다음과 같은 정보를 포함한다.

• 필드명 (Byte 0-10): 최대 11바이트의 ASCII 문자열로 필드의 이름을 저장한다. 이름이 10자보다 짧을 경우, 나머지 공간은 Null 문자(0x00)로 채워진다.

• 필드 타입 (Byte 11): 필드가 저장할 데이터의 종류를 나타내는 한 글자의 코드. 주요 타입은 다음과 같다.12

• C: Character (문자열)

• N: Numeric (숫자)

• L: Logical (논리값, True/False)

• D: Date (날짜)

• M: Memo (대용량 텍스트, .dbt 파일 포인터)

• 필드 길이 (Byte 16): 1바이트 이진 값으로, 해당 필드가 차지하는 바이트 수를 나타낸다. Character 필드의 최대 길이는 254바이트였다.13

• 소수점 자릿수 (Byte 17): 1바이트 이진 값으로, 필드 타입이 Numeric일 경우 소수점 이하 자릿수를 지정한다.

이 필드 디스크립터 배열은 테이블의 스키마(schema) 그 자체이며, dBase가 각 레코드 내에서 특정 필드의 데이터를 어떻게 해석하고 접근해야 하는지에 대한 청사진을 제공한다.

Table 2: dBase III 필드 디스크립터 배열 구조 (32 Bytes)

3.1.3 데이터 레코드 구조

헤더와 필드 디스크립터 배열이 모두 끝난 후, 실제 데이터 레코드들이 순차적으로 저장된다. 모든 레코드는 헤더에 명시된 ’레코드 크기’와 동일한 고정 길이를 가진다. 각 레코드의 구조는 다음과 같다.

• 삭제 플래그 (첫 1바이트): 각 레코드의 시작은 1바이트 크기의 ’삭제 플래그(deletion flag)’이다.13 이 플래그의 값이 공백(ASCII 0x20)이면 유효한 레코드임을, 별표(ASCII 0x2A)이면 삭제된 것으로 표시됨을 의미한다. PACK 명령을 실행하기 전까지 데이터는 물리적으로 제거되지 않고 단지 ’삭제 표시’만 되기 때문에, 실수로 삭제한 레코드를 복구(RECALL 명령)하는 것이 가능했다.

• 필드 데이터: 삭제 플래그 바로 뒤에는 필드 디스크립터에 정의된 순서와 길이에 따라 각 필드의 데이터가 필드 구분자나 레코드 종료자 없이(without field separators or record terminators) 연속적으로 채워진다(packed).15 예를 들어, NAME(C, 10), AGE(N, 3) 두 필드로 구성된 테이블이 있다면, 각 레코드는 [삭제플래그(1바이트)][NAME 데이터(10바이트)][AGE 데이터(3바이트)] 형태로 총 14바이트를 차지하게 된다.

• 파일 종료자: 모든 데이터 레코드가 끝난 후, 파일의 끝은 단일 바이트의 EOF(End-of-File) 마커, 즉 0x1A로 표시된다.15

이처럼 .dbf 포맷의 개방성과 단순함은 dBase 표준화의 핵심 동력이었다. 복잡한 내부 구조 없이 헤더와 순수 데이터로만 이루어져 있어 매우 직관적이고 예측 가능했다. 이 ‘단순함’ 덕분에 Lotus 1-2-3, WordPerfect 등 당대의 다른 주요 소프트웨어들이 .dbf를 데이터 교환 포맷으로 쉽게 채택할 수 있었다.10 이는 dBase를 개별 제품의 경계를 넘어선 산업 표준으로 격상시키는 결정적 계기가 되었다. 즉, dBase의 성공이 .dbf 포맷을 퍼뜨렸고, 널리 퍼진 .dbf 포맷이 다시 dBase의 시장 지배력을 공고히 하는 선순환 구조를 만들어낸 것이다.

3.2 데이터 무결성과 검색 속도: 인덱스와 메모 파일

.dbf 파일이 데이터의 ‘창고’ 역할을 했다면, 인덱스 파일과 메모 파일은 이 창고를 효율적이고 유연하게 사용하기 위한 필수적인 도구였다. 특히 인덱스 파일은 대용량 데이터베이스에서 원하는 정보를 순식간에 찾아내는 dBase의 핵심 성능 비결이었다.

• 단일 인덱스 파일 (.ndx): dBase III Plus는 빠른 데이터 검색을 위해 B-트리 구조 기반의 인덱스 파일을 사용했다. 사용자가 INDEX ON <key_expression> TO <filename> 명령을 실행하면, dBase는 지정된 키 표현식(예: 특정 필드 또는 필드들의 조합)을 기준으로 정렬된 포인터 목록을 담은 .ndx 파일을 생성한다.3 데이터베이스 파일(USE 명령)과 함께 인덱스 파일을 활성화(SET INDEX TO <index_file>)하면, SEEK이나 FIND 같은 명령을 통해 수만, 수십만 건의 레코드 속에서도 특정 값을 거의 즉각적으로 찾아낼 수 있었다. 그러나 dBase III Plus의 .ndx 파일은 하나의 파일이 단 하나의 인덱스 키만 가질 수 있다는 명백한 한계가 있었다. 따라서 이름, 우편번호, 고객번호 등 여러 기준으로 데이터를 검색하려면 각각의 .ndx 파일을 별도로 생성하고 관리해야 했다.16 이는 파일의 개수를 증가시켜 관리를 복잡하게 만드는 요인이 되었고, dBase IV에서 .mdx 파일이 도입되는 직접적인 계기가 되었다.

• 메모 파일 (.dbt): .dbf 파일의 필드 구조는 고정 길이 데이터를 효율적으로 처리하는 데 최적화되어 있었다. 이로 인해 문자(Character) 타입 필드의 최대 길이는 254바이트로 제한되었다.13 이 한계를 넘어서는 가변 길이의 장문 텍스트(예: 상세 설명, 비고, 메모 등)를 저장하기 위해 .dbt(dBASE Text)라는 별도의 파일이 사용되었다.15

.dbf 파일 내에 필드 타입을 ’Memo’로 지정하면, 해당 필드에는 실제 텍스트 데이터가 저장되는 대신 .dbt 파일 내의 512바이트 데이터 블록 시작 위치를 가리키는 10자리 숫자 포인터가 저장된다.15 사용자가 메모 필드를 조회하거나 편집하면, dBase는 이 포인터를 이용해 .dbt 파일의 해당 위치로 이동하여 데이터를 읽거나 쓴다. 이 방식은 고정 길이 레코드 구조의 장점을 유지하면서도 가변 길이의 대용량 텍스트를 효과적으로 처리할 수 있게 해주었다.

3.3 dBase III 프로그래밍 언어

dBase의 성공을 이끈 또 다른 축은 내장된 프로그래밍 언어였다. 이 언어는 데이터베이스 조작에 특화된 4세대 언어(4GL)이자 절차적 프로그래밍 언어로서, 비전문가도 쉽게 배울 수 있는 직관성과 전문 개발자를 위한 강력한 기능을 동시에 제공했다.1 사용자는 ’닷 프롬프트(.)’라 불리는 대화형 명령줄 인터페이스에서 명령어를 한 줄씩 실행하며 즉각적으로 결과를 확인할 수 있었고, 이 명령어들을 순차적으로 텍스트 파일에 저장하면 하나의 프로그램 파일(.prg)이 되었다.10

이러한 절차적 언어와 대화형 인터페이스의 결합은 개발 생산성을 극대화했다. 개발자는 닷 프롬프트에서 데이터의 상태를 실시간으로 탐색하며 로직을 구상하고 테스트한 후, 검증된 명령어 시퀀스를 그대로 프로그램 코드로 옮길 수 있었다. 이는 컴파일-링크-실행 주기가 길었던 당시의 다른 프로그래밍 환경(C, Pascal 등)에 비해 압도적으로 빠른 개발 사이클을 제공했다. 이러한 생산성 덕분에 회계, 재고 관리, 고객 관리 등 수많은 중소기업용 맞춤형 애플리케이션이 dBase로 신속하게 개발되었고, 이는 dBase를 단순한 데이터베이스를 넘어 신속 애플리케이션 개발(RAD, Rapid Application Development) 플랫폼으로 만들며 그 생태계를 폭발적으로 성장시키는 원동력이 되었다.1

dBase III 언어의 핵심 명령어는 다음과 같이 분류할 수 있다.

3.3.1 핵심 데이터 조작 명령어 (DML)

• USE <filename>: 데이터베이스 파일(.dbf)을 열고 특정 작업 영역(work area)에 할당한다. INDEX 절을 사용하여 관련 인덱스 파일(.ndx)을 함께 열고, ALIAS 절로 작업 영역에 별칭을 부여할 수 있다.

• APPEND: 파일의 끝에 새로운 레코드를 추가하기 위한 전체 화면 입력 모드로 전환한다. BLANK 옵션은 사용자 입력 없이 빈 레코드를 프로그래밍 방식으로 추가한다.11

• EDIT / BROWSE: EDIT은 한 번에 한 레코드씩 필드 단위로 데이터를 수정하는 화면을 제공하고, BROWSE는 여러 레코드를 테이블(스프레드시트) 형태로 보여주며 데이터를 탐색하고 수정할 수 있게 한다.11

• REPLACE <field> WITH <expression>: 조건(FOR)에 맞는 레코드들의 특정 필드 값을 새로운 표현식(WITH)의 결과로 변경한다. ALL과 같은 범위(SCOPE) 지정자를 함께 사용할 수 있다.

• DELETE / RECALL / PACK: DELETE는 조건에 맞는 레코드에 삭제 플래그를 표시한다. RECALL은 이 플래그를 제거하여 레코드를 복원한다. PACK은 삭제 플래그가 표시된 모든 레코드를 파일에서 물리적으로 영구 제거하고 파일 크기를 줄인다.

3.3.2 데이터 검색 및 정렬 명령어

• LIST / DISPLAY: 조건에 맞는 레코드의 내용을 화면이나 프린터로 출력한다. LIST는 모든 레코드를, DISPLAY는 기본적으로 현재 레코드만 보여준다.

• INDEX ON <key_expression> TO <index_file>: 지정된 키를 기준으로 .ndx 인덱스 파일을 생성한다. 예를 들어, INDEX ON UPPER(LastName) + FirstName TO NAMES는 성과 이름을 대문자로 변환하여 결합한 값을 키로 하는 NAMES.ndx 파일을 만든다.

• SEEK <expression> / FIND <literal_string>: 활성화된 인덱스를 사용하여 특정 값을 매우 빠르게 찾는다. SEEK은 변수나 표현식의 값을 찾고, FIND는 따옴표로 묶인 문자열 리터럴을 찾는다. 검색에 성공하면 FOUND() 함수가 .T.(True)를 반환한다.

• SORT ON <field> TO <new_filename>: 특정 필드를 기준으로 레코드를 물리적으로 재정렬하여 새로운 .dbf 파일을 생성한다. 인덱싱에 비해 처리 속도가 매우 느리고 추가적인 디스크 공간을 요구하므로, 특별한 경우가 아니면 INDEX가 선호되었다.

3.3.3 관계 설정 및 보고 명령어

• SELECT <work_area>: 여러 개의 데이터베이스 파일을 동시에 열 때, 작업할 파일을 전환한다. dBase는 A-J까지의 문자 또는 1-10까지의 숫자로 구분되는 10개의 작업 영역을 제공했다.

• SET RELATION TO <key_field> INTO <child_alias>: 두 개의 데이터베이스 파일을 공통 키 필드를 기준으로 연결하여 일대다(one-to-many) 관계를 설정한다. 부모 테이블에서 레코드 포인터가 이동하면, 자식 테이블의 포인터도 자동으로 해당 키 값을 가진 첫 번째 레코드로 이동한다. 이는 관계형 데이터베이스의 핵심 기능을 흉내 낸 강력한 기능이었다.

• CREATE REPORT <report_name> / REPORT FORM <report_name>: CREATE REPORT는 안내서 양식(.frm)을 시각적으로 디자인하는 화면을 연다. REPORT FORM은 이 양식을 사용하여 현재 데이터베이스의 내용을 형식에 맞춰 화면이나 프린터로 출력한다.

4. dBase IV: 표준의 진화와 균열

dBase III Plus가 시장을 평정한 후, 애슈턴-테이트는 경쟁자들의 거센 도전을 받았다. Clipper의 컴파일 기능과 FoxBASE의 빠른 속도는 dBase의 약점을 파고들었다. 이에 대응하여 애슈턴-테이트는 dBase 표준을 한 단계 도약시키기 위한 야심 찬 프로젝트, dBase IV를 1988년에 출시했다. dBase IV는 이전 버전과 비교할 수 없을 정도로 혁신적인 기능들을 탑재하며 표준의 진화를 꾀했지만, 그 결과는 오히려 표준의 균열과 시장 리더십의 붕괴로 이어졌다.

4.1 dBase IV의 혁신적 기능

오랜 개발 기간과 수많은 출시 지연 끝에 공개된 dBase IV는 약 300개 이상의 새로운 기능과 개선점을 포함하고 있었다.4 이는 dBase를 단순한 데이터베이스 언어에서 통합 애플리케이션 개발 환경으로 변모시키려는 시도였다.

• 컨트롤 센터(Control Center): dBase III Plus의 텍스트 기반 ’어시스턴트’를 완전히 대체하는 새로운 그래픽 사용자 인터페이스(GUI)였다. 컨트롤 센터는 데이터 파일, 쿼리, 폼, 안내서, 레이블, 애플리케이션 등 dBase의 모든 구성 요소를 6개의 패널로 나누어 통합 관리할 수 있게 했다.19 이는 dBase 역사상 최초로 사용하기 쉬운 통합 환경이라는 긍정적인 평가를 받으며, 사용자가 더 이상 난해한 명령어를 외우지 않아도 되게끔 했다.7

• QBE (Query by Example): 당시 경쟁 제품이었던 Paradox의 가장 큰 인기 요인이었던 QBE 기능을 도입했다.7 사용자는 그래픽 인터페이스 상에서 테이블의 필드에 원하는 조건을 직접 입력하는 방식으로, 복잡한 SQL이나 dBase 명령어를 작성하지 않고도 시각적으로 데이터를 조회하고 필터링할 수 있었다. 이는 비전문가의 데이터 접근성을 획기적으로 향상시킨 기능이었다.

• 스크린/리포트 디자이너 및 애플리케이션 생성기: 기존의 제한적인 디자인 도구를 개선하여, 사용자가 보다 정교하고 미려한 데이터 입력 화면과 안내서를 시각적으로 디자인할 수 있는 WYSIWYG(What You See Is What You Get) 방식의 도구를 제공했다.7 또한, 애플리케이션 생성기(Applications Generator)는 이러한 화면, 메뉴, 안내서 등을 조합하여 프로그래밍 없이도 간단한 메뉴 기반의 데이터베이스 애플리케이션을 자동으로 생성해주는 강력한 기능이었다.7

• SQL (Structured Query Language) 지원: 1980년대 후반부터 관계형 데이터베이스의 표준 언어로 부상하던 SQL을 수용했다. dBase IV는 내장 SQL 인터프리터를 탑재하여, 사용자가 닷 프롬프트에서 직접 SQL 명령(SELECT, INSERT, UPDATE 등)을 실행하거나, .prg 프로그램 파일 내에 SQL 문장을 포함(embedded SQL)시켜 dBase 데이터에 접근할 수 있게 했다.7 하지만 이는 Oracle이나 DB2와 같은 본격적인 RDBMS의 SQL이 아닌, dBase의 파일 기반 엔진 위에서 SQL 문법을 흉내 내는 제한적인 구현이었으며, 성능상의 이점도 크지 않았다.

4.2 dBase IV의 핵심 기술 변화: .mdx 파일

dBase IV가 선보인 수많은 기능 중 기술적으로 가장 중요하고 의미 있는 진보는 **다중 인덱스 파일(.mdx, Multiple Index File)**의 도입이었다.7 이는 dBase III Plus의 단일 인덱스 파일(.ndx) 시스템이 가진 근본적인 불편함을 해결한 혁신적인 변화였다.

dBase III Plus에서는 인덱스가 필요할 때마다 별도의 .ndx 파일을 생성해야 했기 때문에, 하나의 데이터베이스에 여러 개의 인덱스가 연결되면 파일 관리가 매우 번거로워졌다. 반면, dBase IV의 .mdx 파일은 하나의 파일 안에 최대 48개의 서로 다른 인덱스(이를 ’태그(tag)’라 부름)를 함께 저장할 수 있었다.23 이로써 개발자는 단 하나의 인덱스 파일만 관리하면 되었다.

특히 중요한 것은 ‘프로덕션(production) MDX’ 파일의 개념이었다. 프로덕션 MDX 파일은 데이터베이스 파일(.dbf)과 동일한 파일명(확장자만 다름)을 가지며, 해당 .dbf 파일이 USE 명령으로 열릴 때 자동으로 함께 열리고 닫혔다.16 데이터가 추가, 수정, 삭제될 때마다 프로덕션 MDX 파일 내의 모든 관련 인덱스 태그들이 자동으로, 그리고 즉각적으로 업데이트되었다. 이는 개발자가 인덱스 동기화를 위해 별도의REINDEX 명령을 실행하거나 여러 인덱스 파일을 수동으로 관리해야 했던 번거로움을 완전히 없애주었다. 이 기능은 인덱스 관리의 편의성을 극적으로 향상시키고 데이터의 정합성을 유지하는 데 크게 기여한 중요한 발전이었다.7

이러한 .mdx 파일 지원을 위해 .dbf 파일의 헤더 구조에도 변화가 생겼다. dBase IV 레벨의 .dbf 파일 헤더에는 다음과 같은 플래그들이 추가되었다.15

• 헤더 Byte 28 (Production MDX flag): 이 바이트의 값이 0x01이면 해당 .dbf 파일과 연결된 프로덕션 .mdx 파일이 존재함을 의미하고, 0x00이면 없음을 의미한다.

• 필드 디스크립터 Byte 31 (Production MDX field flag): 각 필드 디스크립터의 마지막 바이트는 해당 필드가 프로덕션 .mdx 파일 내에 인덱스 태그로 포함되어 있는지를 나타내는 플래그다. 값이 0x01이면 인덱싱된 필드임을 의미한다.

4.3 실패한 혁명: dBase IV의 기술적 문제와 시장의 외면

이처럼 dBase IV는 기능적, 기술적으로 수많은 혁신을 담고 있었음에도 불구하고, 시장에서는 재앙에 가까운 실패를 경험했다. 그 원인은 명확했다. 애슈턴-테이트는 경쟁 제품의 모든 기능을 따라잡고 그 이상을 제공하려는 야심 찬 목표를 세웠지만, 이로 인해 제품은 지나치게 복잡해졌고 개발 일정은 통제 불능 상태에 빠졌다. 수많은 출시 지연 끝에 시장에 나온 dBase IV 1.0 버전은 심각한 버그로 가득했고, 실행은 극도로 불안정했으며, 당시 PC 환경에서는 감당하기 어려울 정도의 막대한 메모리를 요구했다.4

성능 또한 dBase III Plus에 비해 현저히 느리다는 평가가 지배적이었다.4 완전히 새로 작성된 거대한 C언어 코드베이스는 최적화가 부족했고, 수많은 버그는 잦은 데이터 손상과 시스템 다운을 유발했다. 사용자들은 dBase IV의 화려한 신기능을 제대로 활용해 보기도 전에, dBase III Plus에서는 당연하게 여겼던 기본적인 안정성마저 확보할 수 없다는 사실에 크게 실망했다.

결과적으로, dBase IV는 시장의 신뢰를 완전히 잃어버렸다. 수많은 개발자와 기업 고객들은 불안정한 dBase IV를 버리고, 더 빠르고 안정적이며 이미 검증된 경쟁 제품, 즉 FoxPro나 Clipper와 같은 xBase 클론으로 대거 이탈했다.4 이는 10년 가까이 PC 데이터베이스 시장을 지배해 온 애슈턴-테이트의 몰락을 가속화한 결정적인 사건이었다. dBase IV의 실패는 시장 선도 기업이 경쟁 압박에 쫓겨 기능 과부하(feature creep)에 빠지고 미완성된 제품을 출시했을 때, 기존에 쌓아 올린 브랜드 가치와 시장 점유율이 얼마나 급격하게 붕괴될 수 있는지를 보여주는 소프트웨어 역사상 가장 교과서적인 사례 중 하나로 남게 되었다.

아래 표는 dBase III Plus와 dBase IV의 주요 특징을 비교하여 dBase IV의 잠재력과 실제 실패 사이의 간극을 명확히 보여준다.

Table 3: dBase III Plus vs. dBase IV 기능 비교

5. dBase의 유산과 xBase 생태계

dBase IV의 실패는 애슈턴-테이트의 독점적 지위에 종말을 고했지만, dBase가 만들어낸 표준 자체가 사라진 것은 아니었다. 오히려 dBase 표준은 애슈턴-테이트의 통제를 벗어나 ’xBase’라는 이름의 더 크고 역동적인 생태계로 확장되며 그 생명력을 이어갔다.

5.1 xBase의 탄생: 표준의 개방과 확장

dBase의 높은 시장 지배력은 역설적으로 경쟁 제품, 즉 ’클론(clones)’의 등장을 촉발하는 배경이 되었다. 높은 가격, 상대적으로 느린 성능, 그리고 더딘 기능 개선에 불만을 품은 개발자들은 dBase와 호환되면서도 특정 영역에서 월등한 성능을 제공하는 대안을 찾기 시작했다.4

• Clipper: 1985년 낸터킷(Nantucket)사에서 개발한 Clipper는 dBase 언어 ’컴파일러’였다.29 기존의 dBase 프로그램은 실행을 위해 고가의 dBase 인터프리터가 반드시 필요했고, 소스 코드가 그대로 노출되는 단점이 있었다. 반면, Clipper는 dBase 소스 코드를 독립적으로 실행 가능한 기계어 코드(.exe 파일)로 컴파일해주었다. 이는 두 가지 혁신적인 이점을 제공했다. 첫째, 인터프리터 방식보다 월등히 빠른 실행 속도를 보장했다. 둘째, 컴파일된 실행 파일만 배포하면 되므로 소스 코드를 보호할 수 있었고, 최종 사용자에게 dBase 라이선스 비용을 전가할 필요가 없었다. 이러한 장점들 덕분에 Clipper는 전문 애플리케이션 개발자들 사이에서 폭발적인 인기를 끌며 독자적인 생태계를 구축했다.28

• FoxBASE+/FoxPro: Fox Software에서 개발한 FoxBASE는 dBase III Plus와의 완벽한 호환성을 유지하면서도 압도적으로 빠른 실행 속도를 자랑했다.4 FoxBASE는 dBase 코드를 거의 수정 없이 그대로 실행하면서도 몇 배나 빠른 성능을 보여주었기 때문에, dBase 사용자들에게 매우 매력적인 대안으로 떠올랐다. 이후 FoxPro로 발전하면서 독자적인 언어 확장과 혁신적인 기술(예: Rushmore 최적화 기술)을 거듭하며 dBase의 가장 강력하고 직접적인 경쟁자로 부상했다.32

이러한 클론 제품들의 부상에 대해 애슈턴-테이트는 기술 혁신 대신 법적 대응으로 맞섰다. 그들은 dBase 언어와 파일 포맷이 자사의 독점적 자산이라고 주장하며 Clipper와 FoxPro 등 주요 클론 개발사들을 상대로 상표권 및 저작권 침해 소송을 제기했다.26 이 법적 분쟁을 피하고 공동으로 대응하기 위해, 클론 개발사들과 사용자 커뮤니티는 ’dBase와 유사한 모든 것’을 포괄하는 중립적인 용어인 **‘xBase’**를 사용하기 시작했다.28 이는 dBase 표준의 소유권이 더 이상 애슈턴-테이트라는 단일 기업에 귀속되지 않고, 여러 플레이어들이 참여하는 개방된 생태계로 전환되었음을 상징하는 중요한 사건이었다.

xBase 생태계의 형성을 확정한 결정적 계기는 1991년 보랜드(Borland)가 재정 위기에 처한 애슈턴-테이트를 인수한 사건이었다. 이 인수합병을 승인하는 과정에서 미국 법무부는 시장 독점을 우려하여, 보랜드에게 dBase 언어 사양을 대중에게 공개할 것을 요구했다.28 이 조치로 인해 dBase 언어는 공식적으로 퍼블릭 도메인이 되었고, 누구나 자유롭게 dBase 호환 제품을 개발할 수 있는 법적 토대가 마련되었다. 이후 ANSI 주도로 xBase 언어 표준화를 위한 위원회(X3J19)가 결성되었으나, 이미 각자의 길을 걷고 있던 벤더들(보랜드, 마이크로소프트-FoxPro 인수, 컴퓨터 어소시에이츠-Clipper 인수)의 이해관계가 첨예하게 대립하면서 결국 통일된 표준안을 제정하는 데는 실패했다.28

이 과정은 표준이 통제될 때보다 개방되고 확장될 때 더 강력한 생명력을 가질 수 있음을 보여준다. 애슈턴-테이트는 dBase 표준을 독점적으로 통제하려 했지만, 이는 오히려 혁신적인 경쟁자들을 낳아 xBase라는 더 크고 역동적인 생태계를 만들었다. 역설적으로, 애슈턴-테이트의 통제력 상실이 dBase 언어와 .dbf 포맷의 생명력을 연장시킨 셈이다. dBase라는 제품은 시장에서 사라졌지만, xBase 언어는 Harbour, xHarbour와 같은 현대적인 오픈소스 프로젝트를 통해 현재까지도 그 명맥을 이어가고 있다.30

5.2 dBase 표준의 영향과 현재적 의의

dBase가 PC 데이터베이스 시장의 주역이었던 시대는 지났지만, 그것이 남긴 기술적, 개념적 유산은 현대 컴퓨팅 환경 곳곳에 깊숙이 남아 있다.

• .dbf 포맷의 지속적인 생명력: dBase 자체의 인기는 사그라들었음에도 불구하고, 그 핵심 표준이었던 .dbf 파일 포맷은 놀라울 정도의 생명력을 보여주었다. 단순하고 이식성이 높은 구조 덕분에, .dbf는 수많은 레거시 비즈니스 애플리케이션의 기본 데이터 저장 포맷으로 여전히 사용되고 있다.3 더 나아가, 지리 정보 시스템(GIS) 분야의 사실상 표준인 ESRI Shapefile 포맷에서도 속성 데이터를 저장하는 파일로

.dbf를 채택하고 있다. 이로 인해 최신 데이터베이스 시스템이나 데이터 분석 도구들조차 레거시 데이터와의 호환성을 위해 .dbf 파일 가져오기/내보내기 기능을 지원하는 경우가 많다.14

• 4GL과 RAD 개념의 대중화: dBase는 복잡한 데이터베이스 조작을 USE, LIST, SEEK과 같이 간단하고 직관적인 영어 유사 명령어로 처리하는 4세대 언어(4GL, Fourth-Generation Language)의 개념을 대중화시킨 선구자였다.18 이는 전문 프로그래머가 아니더라도 일반 사용자가 직접 데이터를 다루고 간단한 자동화 스크립트를 작성할 수 있는 길을 열었다. 또한, 닷 프롬프트라는 대화형 개발 환경을 통해 아이디어를 즉시 코드로 구현하고 테스트하며 신속하게 애플리케이션을 제작하는 방식은 오늘날의 신속 애플리케이션 개발(RAD, Rapid Application Development) 패러다임의 원형을 제시한 것으로 평가받는다.26

• PC 데이터베이스 시장의 개척자: 무엇보다 dBase의 가장 큰 유산은 메인프레임과 미니컴퓨터의 전유물이었던 데이터베이스 기술을 개인용 컴퓨터라는 새로운 영역으로 가져와 대중화시켰다는 점이다. dBase는 수많은 중소기업과 개인 사용자들이 저렴한 비용으로 데이터의 힘을 활용하여 비즈니스 효율성을 높일 수 있게 한 시장의 개척자였다.1 dBase가 열어놓은 거대한 PC 데이터베이스 시장과 그 주변에 형성된 개발자 생태계는 이후 Microsoft Access, Paradox, 그리고 클라이언트-서버 시대를 연 Microsoft SQL Server와 같은 후속 데이터베이스 솔루션들이 성장하고 발전할 수 있는 비옥한 토양이 되었다.

6. 결론: 시대를 정의한 표준, 그 영광과 교훈

dBase III와 그 파생 버전들은 1980년대 PC 혁명의 중심에 서 있던 단순한 데이터베이스 관리 시스템 그 이상이었다. 그것은 데이터 관리의 ’공용어’이자, 비즈니스 컴퓨팅의 패러다임을 바꾼 핵심 동력이었다. 본 안내서에서 분석한 바와 같이, ’dBase 표준’은 기술 명세서에만 존재하는 정적인 개념이 아니었다. 그것은 .dbf 파일 포맷이 제공하는 상호운용성, dBase 프로그래밍 언어의 탁월한 접근성, 그리고 이를 둘러싸고 자생적으로 성장한 거대한 개발자 및 지원 생태계의 총체였다.

dBase의 역사는 하나의 중요한 사실을 명확히 보여준다. 기술적 우위만으로는 시장 표준의 지위를 영원히 유지할 수 없다는 것이다. dBase III Plus는 당대 최고의 기술은 아니었을지 몰라도, 시장의 요구에 부응하는 충분한 기능과 압도적인 안정성을 제공하며 표준으로 군림했다. 반면, 기술적으로 수많은 혁신을 담았던 dBase IV는 품질 관리 실패와 사용자 신뢰 상실이라는 치명적인 대가를 치르며 몰락했다. 이는 표준의 지속 가능성이란 시장의 요구에 대한 민첩한 대응, 안정적인 품질 제공, 그리고 경쟁과 협력을 포용하는 개방적인 생태계 관리 능력에 의해 결정됨을 보여주는 강력한 증거다.

dBase IV의 실패는 오늘날의 소프트웨어 개발 및 프로젝트 관리 분야에도 여전히 유효한 교훈을 남긴다. 기능적 혁신에 대한 과도한 집착이 기술적 안정성과 사용자 경험을 담보하지 못할 때, 그것이 어떻게 기업의 리더십을 한순간에 무너뜨릴 수 있는지에 대한 생생한 사례 연구를 제공한다.

결론적으로, dBase는 PC 데이터베이스 시대를 열고 정의한 위대한 표준이었다. 비록 시장의 주역 자리는 후발주자들에게 내주었지만, dBase가 남긴 표준의 유산은 수많은 레거시 시스템의 .dbf 파일 속에, xBase 언어의 명맥을 잇는 오픈소스 프로젝트 속에, 그리고 데이터베이스 기술을 대중화시킨 그 선구적인 정신 속에 여전히 살아 숨 쉬고 있다.

7. 참고 자료

1. dBASE Explained: Your Friendly Guide - CelerData, https://celerdata.com/glossary/dbase-explained
2. 30 Years Ago: The Rise, Fall and Survival of Ashton-Tate’s dBASE - eWeek, https://www.eweek.com/database/30-years-ago-the-rise-fall-and-survival-of-ashton-tate-s-dbase/
3. dBase: Pioneering Personal Database Management Solutions …, https://www.lenovo.com/us/en/glossary/dbase/
4. dBase - Wikipedia, https://en.wikipedia.org/wiki/DBase
5. Ashton-Tate - Wikipedia, https://en.wikipedia.org/wiki/Ashton-Tate
6. TIL that dBASE, the database software, was created to win football pools. It became so successful that its creator no longer had time to watch football games. : r/todayilearned - Reddit, https://www.reddit.com/r/todayilearned/comments/1jubdgi/til_that_dbase_the_database_software_was_created/
7. dBASE - DOS Days, http://dosdays.co.uk/topics/Software/dbase.php
8. A personal History of dBase, https://www.dbase.com/Knowledgebase/dbulletin/bu03_b.htm
9. Ashton-Tate - Computer History Museum - Archive Server, http://archive.computerhistory.org/resources/access/text/2012/10/102746512-05-01-acc.pdf
10. dBASE III PLUS - Computer History Museum - Archive Server, https://archive.computerhistory.org/resources/access/text/2016/12/102762706-05-01-acc.pdf
11. Dbase III Plus Tutorial | PDF | Database Index | Computer File - Scribd, https://www.scribd.com/document/362011034/Dbase-III-Plus-Tutorial
12. Structure of the dBase III file. - Promotic, https://www.promotic.eu/en/pmdoc/Subsystems/Db/dBase/DbfFormat.htm
13. What is a DBF Format (2025 Update) - DBF Viewer, https://www.dbf2002.com/dbf-file-format.html
14. dBase - Spectral Core, https://www.spectralcore.com/databases/dbase
15. dBASE III,IV,5 DBF file format - OoCities, https://www.oocities.org/geoff_wass/dBASE/GaryWhite/dBASE/FAQ/qformt.htm
16. dBASE Indexes - Open Database Connectivity (ODBC) | Microsoft Learn, https://learn.microsoft.com/en-us/sql/odbc/microsoft/dbase-indexes?view=sql-server-ver17
17. Why does dbase save files with the same name in 3 different extensions(*.mdx, *.dbf, *.dbt)?, https://stackoverflow.com/questions/72861338/why-does-dbase-save-files-with-the-same-name-in-3-different-extensions-mdx
18. XBase - EDM2, https://www.edm2.com/index.php/XBase
19. About dBase IV, https://people.cs.pitt.edu/~chang/156/06dbase.html
20. www.piclist.com, http://www.piclist.com/techref/language/dbase/commands.htm
21. dBase IV: A Review, https://www.emerald.com/insight/content/doi/10.1108/eb047763/full/pdf
22. Definition of dBASE versions | PCMag, https://www.pcmag.com/encyclopedia/term/dbase-versions
23. Dbase iv format, https://assets-global.website-files.com/6754b52fe5c867c4164ed80a/67f9e47e7176374ebfb42e60_gubikawelufopug.pdf
24. .dbf - Wikipedia, https://en.wikipedia.org/wiki/.dbf
25. Exploring Borland dBase IV for DOS : r/programming - Reddit, https://www.reddit.com/r/programming/comments/ly3ge1/exploring_borland_dbase_iv_for_dos/
26. Ex Base - C2 wiki, https://wiki.c2.com/?ExBase
27. Retro Database dBASE Making a Comeback? - Visual Studio Magazine, https://visualstudiomagazine.com/blogs/data-driver/2013/03/dbase-updated.aspx
28. xBase - Wikipedia, https://en.wikipedia.org/wiki/XBase
29. About Clipper, https://vivaclipper.wordpress.com/category/clipper/about-clipper/
30. Clipper (programming language) - Wikipedia, https://en.wikipedia.org/wiki/Clipper_(programming_language)
31. Compile dBASE III Plus prg files on Harbour - Google Groups, https://groups.google.com/g/harbour-users/c/mjKORiZei1A
32. interpreter | Viva Clipper ! - WordPress.com, https://vivaclipper.wordpress.com/tag/interpreter/
33. Harbour – the history of XBASE languages - BlogFaq400, https://blog.faq400.com/en/03-open-source-en/harbour-the-history-of-xbase-languages/